💚 💙 💜 💛 ❤️

Hi, @v0idpwn! Are you using this feature in development, or in production too? If you're using it in production, would you mind sharing how are you storing the stacktraces for later analysis?

Hello, @gmile. Our intention here was improving development logs (paired with elixir-ecto/ecto_sql#366). For production environment, the existing approaches to trace and correlate queries with spans are usually more than enough in my experience. I don't know about how appsignal in particular does it, but with opentelemetry you will always be able to relate queries to calling code.

@v0idpwn well noted on improving development logs, thanks for making this possible!

but with opentelemetry you will always be able to relate queries to calling code

I am actively studying OpenTelemetry right now, but am failing to see an out-of-the-box (e.g. provided by a package + configuration) solution 🤔 Would you happen to have an example of how to configure Ecto + OpenTelemetry to make Ecto include Ecto stacktraces in spans? I have briefly looked into opentelemetry-ecto (specifically, this part), but it doesn't seem to be including into spans out of the box - it seems like some custom coding might be needed 🤔

@gmile it doesn't include the stacktrace, but it does include the "span-trace" (I mean the tree of spans that ran the query), which is generally better than a stack-trace for most cases, no?

@v0idpwn in the grand scheme of things, a tree of spans (together constituting, what I understand, what's known as a "a trace") is enough for most cases, I agree. But what I am looking for is more resolution, so to say. For example, I want to select a given span coming from Ecto, and be able to find the file/line that produced that span - as quickly as possible.

Basically, I want to do what another person was asking in original issue here elixir-ecto/ecto_sql#364, e.g. "I need the line number in the code", but available in production.